Security Wine (бывший - DevSecOps Wine)

What does your code use, and is it vulnerable? It depends!

Когда дело доходит до внедрения практики выявления уязвимостей в сторонних библиотеках, первое, что часто приходит на ум - внедрить инструмент класса SCA, получить уязвимые библиотеки и получить с разработчика обещание все исправить. При таком подходе мы сталкиваемся со встречными вопросами:
- откуда у вас уверенность, что в транзитивных зависимостях есть эксплуатируемые уязвимости,
- как определить версию директивной зависимости, чтобы обновить транзитивную
- можете ли вы полагаться на перечень зависимостей, который для вас определил SCA (например, в том же package.json может быть указано, что пакет lodash имеет версию "*")

На все эти вопросы ответить сразу на первых этапах внедрения практики не всегда удается успешно. Например, в случае, если мы имеем gradle, то build.gradle никак не даст ответов на вопросы выше, а результатом сборки в данном случае будет набор библиотек, лежащих в единой директории. Что из этого директивная зависимость,а что транзитивная по итогу анализа результатов SCA понять редко возможно. Приходится смотреть дерево зависимотей от самого gradle и сопоставлять с результатами SCA, из-за чего TTM сильно возрастает.

Часто компании принимают для себя решение просить исправлять только уязвимые директивные зависимости, а контроль устранения уязвимостей в транзитивных зависимостях отдавать на авторов директивных. Это решает часть проблем с объемом работы, но часть вопросов выше остаются актуальными.

В данном случае нам могут помочь несколько вещей. Один из простых и эффективных способов - получить lockfile! Это формат описания зависимостей с указанием явных хэш-сумм (а именно на хэш-суммы, как правило, смотрят все SCA, что сразу повышает точность сканирования). Что удобно, так это то, что lockfile можно получить нативным образом от всех популярных сборщиков (pipenv, npm, yarn, nuget, gradle, composer).

Второе решение - построить граф зависимостей и явно отсечь зависимости с глубиной выше 1. Здесь может помочь инструмент вроде It-Depends от Trail of Bits. Он построит вам перечень зависимостей с нужной глубиной и отдаст результат в формате SBOM, который можно скормить в SCA. Кроме того, он может выдать некоторые уязвимости на основе OSV vulnerability database, про которую я писал ранее.

#sca #dev

www.tg-me.com/in/DevSecOps Wine/com.sec_devops/569

6.4K viewsDenis Yakimov, edited  Feb 3, 2022 at 05:57

What does your code use, and is it vulnerable? It depends!

Когда дело доходит до внедрения практики выявления уязвимостей в сторонних библиотеках, первое, что часто приходит на ум - внедрить инструмент класса SCA, получить уязвимые библиотеки и получить с разработчика обещание все исправить. При таком подходе мы сталкиваемся со встречными вопросами:
- откуда у вас уверенность, что в транзитивных зависимостях есть эксплуатируемые уязвимости,
- как определить версию директивной зависимости, чтобы обновить транзитивную
- можете ли вы полагаться на перечень зависимостей, который для вас определил SCA (например, в том же package.json может быть указано, что пакет lodash имеет версию "*")

На все эти вопросы ответить сразу на первых этапах внедрения практики не всегда удается успешно. Например, в случае, если мы имеем gradle, то build.gradle никак не даст ответов на вопросы выше, а результатом сборки в данном случае будет набор библиотек, лежащих в единой директории. Что из этого директивная зависимость,а что транзитивная по итогу анализа результатов SCA понять редко возможно. Приходится смотреть дерево зависимотей от самого gradle и сопоставлять с результатами SCA, из-за чего TTM сильно возрастает.

Часто компании принимают для себя решение просить исправлять только уязвимые директивные зависимости, а контроль устранения уязвимостей в транзитивных зависимостях отдавать на авторов директивных. Это решает часть проблем с объемом работы, но часть вопросов выше остаются актуальными.

В данном случае нам могут помочь несколько вещей. Один из простых и эффективных способов - получить lockfile! Это формат описания зависимостей с указанием явных хэш-сумм (а именно на хэш-суммы, как правило, смотрят все SCA, что сразу повышает точность сканирования). Что удобно, так это то, что lockfile можно получить нативным образом от всех популярных сборщиков (pipenv, npm, yarn, nuget, gradle, composer).

Второе решение - построить граф зависимостей и явно отсечь зависимости с глубиной выше 1. Здесь может помочь инструмент вроде It-Depends от Trail of Bits. Он построит вам перечень зависимостей с нужной глубиной и отдаст результат в формате SBOM, который можно скормить в SCA. Кроме того, он может выдать некоторые уязвимости на основе OSV vulnerability database, про которую я писал ранее.

#sca #dev

BY Security Wine (бывший - DevSecOps Wine)